Celestin Apprentice 5/Apprentice-Release5.iso/Information/CSMP Digest/volume 1/csmp-v1-144.txt

Text File | 1992-12-31 | 45KB | 1,249 lines

C.S.M.P. Digest             Sun, 19 Jul 92       Volume 1 : Issue 144

Today's Topics:

    Changing Parameter Ram. Help!
    How to use icon suites in menu items?
    The need for speed: data and instruction caches. (SUMMARY)
    Reading File Problems....
    Pascal string to null terminated-How?
    Changing a folder view
    Dave Mark : Macintosh C Programming
    Think C menu question



The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  (This means you can't post questions to the
digest.)

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
cs.uoregon.edu).  Article threads are not added to the digest until the last
article added to the thread is at least one month old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The entire digest is available for anonymous ftp from ftp.cs.uoregon.edu
[128.223.8.8] in the directory /pub/mac/csmp-digest.  The most recent issues
are available from sumex-aim.stanford.edu [36.44.0.6] in the directory
/info-mac/digest/csmp.  If you don't have ftp capability, the sumex archive
has a mail server; send a message with the text '$MACarch help' (no quotes)
to [e-mail] for more information.

The digest is also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new issue as it is created.  Sorry, back issues
are not available through the mailing list.

Send administrative mail to [e-mail].


-------------------------------------------------------

Subject: Changing Parameter Ram. Help!
From: [e-mail] (Martin J. Miller)
Date: 2 Jun 92 15:33:49 +1200
Organization: Computer Science,University of Canterbury,New Zealand

   I am writing an INIT/cdev combination to alter the parameter ram (namely:
mouse click, keyboard repeat/delay, sound volume, carat blink, menu blink).
   I can change the pRAM but the system fails to notice until restart.
(The changes are visible in Apple written cdevs, but the system does not
utilize the new settings until restart [ie their is an inconsistency
between the pram and what the system uses])
   What must you do other than the following to make the changes visible?
pSysParms := GetSysPPtr ;
 { do some change on pSysParms^ }
iErr := WriteParam ;
{ This is happily returning 0 and the status in pSysParms is good }
   Also what does readxpram and writexpram do? And what are their
parameters (if any)?

Any help would be most appreciated.
   Thanks Martin Miller.
ps Unfortuantely I can't reply to any emails as I am only an undergraduate
student and was only granted this posting as an exception nor can I remote
ftp!

+++++++++++++++++++++++++++

From: Andreas Wuertz <[e-mail]>
Organization: ETH TIK
Date: Tue, 16 Jun 1992 15:31:39 GMT

>pSysParms := GetSysPPtr ;

Andy from TIK

=======================================================
The earliest time for a program to be bug-free is,
when it's out of date. The latest time for a programmer
to retire is, when he writes such a program.
=======================================================

+++++++++++++++++++++++++++

From: Andreas Wuertz <[e-mail]>
Organization: ETH TIK
Date: Tue, 16 Jun 1992 15:33:08 GMT

Maybe you also need to update the low memory globals.
See interface file 'SysEqu.p' for exact vars to change.
The rule is: if it's mentioned in Inside Mac, you may use
it. Mostly you find mentions of the vars in the assembly
language notes or in chapter summaries.

Example:
File 'SysEqu.p':
SPVolCtl = $208; {Speaker volume setting in parameter RAM (byte)}
SdVolume = $260; {Current speaker volume (byte:  low-order three bits
only)
^^^^SEE, there are TWO vars... find out yourself (using IM) which one to
use (or even both).

Your Code:
PROGRAM SetVolToOne;
USES Types, SysEqu;
VAR theVolume: Ptr; { which is ^SignedByte }
BEGIN
    theVolume:=Ptr(SPVolCtl);
    theVolume^:=1; { sets the volume to 1 }
END.

Hope this helps.

---------------------------

From: [e-mail] (Ben Hekster)
Subject: How to use icon suites in menu items?
Date: 2 Jun 92 03:47:45 GMT
Organization: University of Twente, Dept. of Computer Science

Does anyone know how to get icon suites in menu items?  Like the
Apple and process menus do.

    From stepping through the menu bar definition function I've
found that you can get an icon suite as a menu *title* by setting
the title to a five-character string, with the first character as a
'0x01' and the remaining four characters as the icon handle.  However,
I haven't found how to get SuiteIcons into menu *items*.  I've tried
doing the same but it doesn't work.

    It looks as if the handling of both the Apple and process
menus is special-cased inside the 'MBDF'.  In both cases it calls
_OSDispatch to get the icon handles to display.  Does this mean there
is no interface for this yet?

    Has anyone looked into this?  I think I checked all the
relevant Technical Notes (including the recently updated TN 306) but
I can't find any mention of it.

- --
Ben `Hackster' Hekster        | "Die Qualita:t des Lebens
[e-mail]        |  Aus kleinem, intelligentem Element"

+++++++++++++++++++++++++++

From: Andreas Wuertz <[e-mail]>
Organization: ETH TIK
Date: Tue, 16 Jun 1992 15:47:13 GMT

>I can't find any mention of it.

You can't find any mention, but you can simply DO
it using ResEdit 2.1.1: Create a menu, create an
item for that menu and choose 'Set Icon' from the
'Menu'-menu. Say 'Small Icon Resource' and 'New'
in the upcoming dialog and see (opening the menu
with the MENU-Template, not the MENU-Editor) how
ResEdit has done magic and provided an Icon ID of
94 (or so) and created an SICN of ID 352. But it
works! I'm sure one could find out the relation
between the two numbers, but why if resedit does
it? No the next clue: add a 'cicn' with same id
as the SICN (352, not 94) and you get a menu item
with a colour small icon!

Hope this works on YOUR mac, too... :-)

Andy from TIK

=======================================================
The earliest time for a program to be bug-free is,
when it's out of date. The latest time for a programmer
to retire is, when he writes such a program.
=======================================================

---------------------------

From: [e-mail] (Jesse Jones)
Subject: The need for speed: data and instruction caches. (SUMMARY)
Date: 10 Jun 92 16:17:37 GMT
Organization: University of Washington, Seattle


             The need for speed: data and instruction caches.

   I posted an article a while back asking about how the data caches on the
Quadra worked. I'm the author of a fractal program that ran at about the
same speed on a Quadra and an SE/30. It turns out that the algorithm I
used was just about the worst possible for the '040.

   I received several replies to my original article. William Graham was
kind enough to send me some excerpts from a two part article on the '040 in
the February 1990 and June 1990 IEEE Micro. Harry Eaton mailed me a copy of
TN 261 Cache as Cache can (I got a corrupted file when I tried to FTP it).

   I'm posting this summary because several of the people who replied to
my article seemed confused about how the '040s caches worked. Tech Note 261
is well written but doesn't discuss how the caches actually work. (It's
basicly a primer on how to write your programs so that they are  compatible
with the caches).

Here's how the caches are organized on the various processors:

Processor      Instruction      Data
68020          64 long-words    none

68030          64 long-words    64 long-words (write-through)

68040          256 lines        256 lines (each line is 16 bytes)

   The caches on the '020 and '030 are 256 bytes. The caches on the '040
are a whopping 4096 bytes. The caches work on blocks of memory. For the
'020 and '030 each cache entry is a long-word. For the '040 a cache entry
is 16 bytes. So, for example, on a '040 if a word at some address A is
cached the following 14 bytes will be cached as well.

   The cache modes control how cache entries are allocated and when data is
written to memory. They work as follows:

Copy-Back mode keeps data in the cache without writing it to memory. Data is
written to memory only when a cache entry is de-allocated. Cache entries are
allocated whenever a WRITE fails.

Write-Through writes changes to both the cache and memory. Cache entries are
allocated on READs.

   A large part of the performance of the Quadras is due to the instruction
and data caches. If the caches are not used effectively performance will
take a nose dive. It's important to keep your memory accesses as clustered
as possible so that as much of the cache entry is used as possible (this is
where I went wrong). The cache mode is also important. It should be changed
depending on if you are reading or writing to the same locations frequently.

   --Jesse

+++++++++++++++++++++++++++

From: [e-mail] (Steven J. Edwards)
Organization: Bull HN, Worldwide Information Systems, Billerica, Mass., USA
Date: 10 Jun 92 14:20:47

In article <[e-mail]> [e-mail] (Jesse Jones) writes:
>   Here's how the caches are organized on the various processors:
>
> Processor      Instruction      Data
> 68020          64 long-words    none
>
> 68030          64 long-words    64 long-words (write-through)
>
> 68040          256 lines        256 lines (each line is 16 bytes)
>
>    The caches on the '020 and '030 are 256 bytes. The caches on the '040
> are a whopping 4096 bytes. The caches work on blocks of memory. For the
> '020 and '030 each cache entry is a long-word. For the '040 a cache entry
> is 16 bytes. So, for example, on a '040 if a word at some address A is
> cached the following 14 bytes will be cached as well.

Actually, it's not necessarially "the following 14 bytes" that are
cached in the '040.  Rather, each line of cache in use at a particular
time is associated with a sixteen byte long chunk of memory starting
at an address that is 16 byte aligned.  Similarly, the '030 and '020
lines cache four byte chunks that correspond to 4 byte aligned memory
addresses.

And to no one in particular:

Commandment 0x1b2f says:

Thou shall not write self modifying code for it displeaseth thy fellow
programmers to hear the same sad song when thou doest complaineth
afterwards showing thy ignorance of cache mechanics.

 [The above opinions expressed are my own; not necessarily held by others.]
      == Steven J. Edwards           Bull HN Information Systems Inc. ==
      == [phone]              300 Concord Road         MS 820A ==
      == [e-mail]     Billerica, MA 01821          USA ==
"That Government which Governs the Least, Governs Best." -- Thomas Jefferson

+++++++++++++++++++++++++++

From: [e-mail] (Scott Bayes)
Date: Mon, 15 Jun 1992 22:15:38 GMT
Organization: Hewlett-Packard Co., Loveland, CO

> Copy-Back mode keeps data in the cache without writing it to memory. Data is
> written to memory only when a cache entry is de-allocated. Cache entries are
> allocated whenever a WRITE fails.

Note that the amount of data written to RAM when the entry is flushed
may vary.

The cacheline is laid out so (logically)

L1 L2 L3 L4 D1 D2 D3 D4

Where Li are longwords, and Di are dirty bits associated with them.

If exactly one longword in the cacheline is marked "dirty" (any byte or
word or the whole longword has been modified by the CPU), only it is
flushed.  If more than one has been so marked, the whole cacheline is
written back to RAM.

This can lead to interesting interactions with DMA, if "bus-snooping" is
not enabled.

Say a DMA buffer is in RAM aligned so that it doesn't cover completely
the cache line at one end or the other of the cacheline.  In that part
of the cacheline, you put a variable.

Now, you start an inbound DMA transfer to the buffer.  All the data
arrives, but, because bus-snooping is turned off, the CPU doesn't know
that the data in the buffer is new.  Meanwhile, the value of the
variable is changed, dirtying the cacheline to some extent.  If that
line happens to be flushed before the data in the buffer part of it is
used, the old, "stale" contents of the line get flushed back over the
buffer, corrupting it.

This actually happened on our non-Mac 68040 CPU, where bus-snooping does
not work correctly, so is disabled.  It was _very_ tough to find.

Scott Bayes

---------------------------

From: [e-mail] (James Edwards)
Subject: Reading File Problems....
Organization: George Mason University, Fairfax, Va.
Date: Wed, 10 Jun 1992 19:33:22 GMT

I have a problem doing some file manipulation, and was wondering if
anyone could help out.  I am writing a program in Think C 5.0, that
basically reads in a text file, which can sometimes be over 200K, pull
some data out, and write that data to another text file.  This should be
very straight forward.  I am not using the ANSI routines because I need
this to be Mac friendly, so am using SFGetFile and FSCreate, FSOpen, and
all those other high-level file routines.  My problem is this:

When I read in the file, I get an error from the SetFPos routine when I
try and set it beyond 32K.  I know the variables are all type long, so I
can't be overloading an integer, I'm not using TextEdit in any way, so I
shouldn't be running into any limitations there, I just can't figure it
out.  I know that Think C has a 32K limitation on the size of an array,
so I am only reading in 10000 bytes at a time, processing them, writing
them out, and then moving the pointer and reading the next 10000.  I have
scanned the Inside Macs as best I could, and couldn't find any reference
to why this wouldn't work.  If someone out there could please let me know
if this is a built in limitation, or how to get around it.  It really
makes me sick, I could have had this done days ago writing it in
something like QBasic....

Jimi

[e-mail]


+++++++++++++++++++++++++++

From: [e-mail] (David Phillip Oster)
Organization: Whole Earth 'Lectronic Link
Date: Sat, 13 Jun 1992 04:53:02 GMT

In article <[e-mail]> [e-mail] (James Edwards) writes:
>out.  I know that Think C has a 32K limitation on the size of an array,
Not so! In the current version, check the "far data" option tto allow larger
gloabl arrays. Local arrays are limited by the size of the stack, and by the
instructions generated to create a stack frame, but for please use NewPtr().
That is what it is there for. If you have the heapo space, there is no
problem with:
GetEOF(ref, &len);
buf = NewPtr(len);
FSRead(ref, &len, buf);

(Always check for errors in a real program.)
and SetFPos(ref, fsFromStart, where    works fine too.
Make sure that "where" is declared long, and that it is initialized via
a properly cast expression. Right:
long where = 500L * sizeof(MyStruct);
Wrong:
long where = (long) shortVar * shortVar;

(I use ((long) shortVar) * shortVar) for safety.)  Use the source level
debugger (in think C) it will tell you whether someting is screwing up
the sign extension of your intermediate calculations.

+++++++++++++++++++++++++++

From: [e-mail] (Michael Kahl)
Organization: Enginuity Inc.
Date: Tue, 16 Jun 1992 13:43:04 GMT

In article <[e-mail]> [e-mail] (David Phillip Oster) writes:
>Local arrays are limited by the size of the stack, and by the
>instructions generated to create a stack frame, ...

THINK C 5 knows how to generate code for large stack frames, although it is
still up to you to assure sufficient stack space by calling SetApplLimit.

>Make sure that "where" is declared long, and that it is initialized via
>a properly cast expression. Right:
>long where = 500L * sizeof(MyStruct);
>Wrong:
>long where = (long) shortVar * shortVar;

This is not wrong.  Casts bind tighter than multiplication.

- --
Michael Kahl      [e-mail]
Disclaimer:  Whoa!  Did I say THAT??!

---------------------------

Subject: Pascal string to null terminated-How?
From: [e-mail]
Date: 15 Jun 92 06:51:19 CST
Organization: University of Kansas Academic Computing Serces

This is a quick one but I am at a loss.  How do I convert a pascal
string to a null terminated string.  What I need is something like
Hypercard's PasToZero function. I have an example in C but I
am using Pascal.  Thanks.

[e-mail]
or
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 15 Jun 92 20:31:15 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail]
writes:
>
> This is a quick one but I am at a loss.  How do I convert a pascal
> string to a null terminated string.  What I need is something like
> Hypercard's PasToZero function. I have an example in C but I
> am using Pascal.  Thanks.

With MPW, in Strings.p, there is a function call P2CStr that converts a string
"in place" (meaning that the memory holding the pascal string ends up holding a
c-string).

I don't know if THINK Pascal has the same function.

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.


+++++++++++++++++++++++++++

From: [e-mail] (Eric Brunson)
Organization: Vista-Chrome Incorporated
Date: Tue, 16 Jun 1992 13:02:31 GMT

[e-mail] (Keith Rollin) writes:

>In article <[e-mail]>, [e-mail]
>writes:
>>
>> This is a quick one but I am at a loss.  How do I convert a pascal
>> string to a null terminated string.  What I need is something like
>> Hypercard's PasToZero function. I have an example in C but I
>> am using Pascal.  Thanks.

>With MPW, in Strings.p, there is a function call P2CStr that converts a string
>"in place" (meaning that the memory holding the pascal string ends up holding a
>c-string).

>I don't know if THINK Pascal has the same function.

Rather than convert back and forth between C and Pascal strings, I have
a simple function to null terminate the P string:

void termPstr( char *string )
{
    string[ string[0] + 1 ] = 0;
}

Then, if I ever need to pass a pointer to a C string I pass string+1,
and use string normally as a Pascal string.  ( Checking the bounds of
the memory allocated to the original string is left as an exercise. )

If you wanted to write your own PtoCStr this works:

void PtoCstr( char *string )
{
    BlockMove( string + 1, string, string[0] );
}

Something similar could be used for CtoPstr using strlen for the length
og the C string.

Hope this helps...

- --
Eric Brunson               These opinions are mine alone,
[e-mail]         but they could be yours for a low monthly fee!
"He's a genius, eh, he hooked up our stereo."

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Organization: Kalamazoo College
Date: Tue, 16 Jun 1992 14:11:31 GMT

[e-mail] (Eric Brunson) writes:
>
>If you wanted to write your own PtoCStr this works:
>
>void PtoCstr( char *string )
>{
>    BlockMove( string + 1, string, string[0] );
>}

Nope.  It doesn't guarantee zero-termination, and bombs with strings
longer than 127 chars.  Try

void newAndImprovedPToCStr(register unsigned char *string)
{
    register short length = string[0];
    BlockMove( string+1, string, length );
    string[length] = '\0';
}
- --
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 Never make MENU resources purgeable.

---------------------------

From: [e-mail] (Chris Silverberg)
Subject: Changing a folder view
Organization: Worcester Polytechnic Institute
Date: Tue, 16 Jun 1992 02:42:06 GMT

I have a program that creates some folders and I would *like* to set the view
within the program (by name, icon, etc.)  But how to accomplish this doesn't
seem to be documented anywhere, unless it's hidden in a technote somewhere.
Does anyone have the insides scoop?

THINK Reference says of the DInfo structure: "The content of the frView field
is not documented, the high byte of this field is one of: 1 By Icon,
2 By Name, 3 By Date, 4 By Size, 5 By Kind, 6 By Color."

So here is my code to attempt to change a directory to By Name.  Note
that the PBSetCatInfo and PBGetCatInfo return 'noErr', but the also dont seem
to work.



void MakeDir( Str255 mailPath )
{
   int            err;
   CInfoPBRec    cipb;
   DirInfo        *theDir = (DirInfo *) &cipb;

   DirCreate( 0, 0L, mailPath, NIL_POINTER );  /* <-- this works fine */
   theDir->ioNamePtr = mailPath;
   theDir->ioVRefNum = 0;
   theDir->ioDrDirID = 0L;
   theDir->ioFDirIndex = 0;
   err = PBGetCatInfo( &cipb, FALSE );         /* no error */
   if ( err != noErr )
      /* process error */
   theDir->ioDrDirID = 0L;

   (theDir->ioDrUsrWds).frView = (2*256)+((theDir->ioDrUsrWds).frView % 256 );
   err = PBSetCatInfo( &cipb, FALSE );          /* no error, but no   */
   if ( err != noErr )                          /* change either      */
      /* process error */
}


 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
   Chris Silverberg                     INTERNET: [e-mail]
   Worcester Polytechnic Institute      WMUG BBS  508-832-5844 (TeleFinder)
   America Online: TfChris              FIDONET:  1:322/115.1

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 16 Jun 92 17:26:40 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail] (Chris
Silverberg) writes:
>
> I have a program that creates some folders and I would *like* to set the view
> within the program (by name, icon, etc.)  But how to accomplish this doesn't
> seem to be documented anywhere, unless it's hidden in a technote somewhere.
> Does anyone have the insides scoop?
>
> THINK Reference says of the DInfo structure: "The content of the frView field
> is not documented, the high byte of this field is one of: 1 By Icon,
> 2 By Name, 3 By Date, 4 By Size, 5 By Kind, 6 By Color."
>
> So here is my code to attempt to change a directory to By Name.  Note
> that the PBSetCatInfo and PBGetCatInfo return 'noErr', but the also dont seem
> to work.
>
> void MakeDir( Str255 mailPath )
> {
>    int            err;
>    CInfoPBRec    cipb;
>    DirInfo        *theDir = (DirInfo *) &cipb;
>
>    DirCreate( 0, 0L, mailPath, NIL_POINTER );  /* <-- this works fine */
>    theDir->ioNamePtr = mailPath;
>    theDir->ioVRefNum = 0;
>    theDir->ioDrDirID = 0L;
>    theDir->ioFDirIndex = 0;
>    err = PBGetCatInfo( &cipb, FALSE );         /* no error */
>    if ( err != noErr )
>       /* process error */
>    theDir->ioDrDirID = 0L;
>
>    (theDir->ioDrUsrWds).frView = (2*256)+((theDir->ioDrUsrWds).frView % 256 );
>    err = PBSetCatInfo( &cipb, FALSE );          /* no error, but no   */
>    if ( err != noErr )                          /* change either      */
>       /* process error */
> }

You'll probably have to set the "inited" bit in the Finder flags, or else the
Finder will imprint its own idea of what the folder should look like the first
time you open it up.

By the way, I think the following information is accurate for 7.0:

                Upper byte                    Lower byte
                ----------                    ---------

                1 = spatial view        bit 0 =
                       (by icon or         bit 1 =
                       small icon)            bit 2 =
                2 = by name                   bit 3 =
                3 = by date                   bit 4 =
                4 = by size                   bit 5 = 1 means window is zoomed
                5 = by kind                   bit 6 = 1 means spatial view
                6 = by comments                          is by small icon
                7 = by label               bit 7 =
                8 = by version

The upper byte of frView is zero for some folders (like the Desktop folder). I'm
not sure what that means.

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.


---------------------------

From: [e-mail] (Frank Mattes)
Subject: Dave Mark : Macintosh C Programming
Date: 16 Jun 92 12:35:12 GMT
Organization: EMBnet Switzerland [Basel]

In this group I have read about the book from Dave Mark, Macintosh C ProgrammingPrimer, Volume I. Does anybody knows which is the newest editon of this book.

Thanks for your help

Frank

+++++++++++++++++++++++++++

From: [e-mail] (Brian D. Davison)
Date: 16 Jun 92 14:06:42 GMT
Organization: Rutgers Univ., New Brunswick, N.J.

In article <mattes.708698112@biox>, [e-mail] (Frank Mattes) writes:
> In this group I have read about the book from Dave Mark, Macintosh C
> ProgrammingPrimer, Volume I. Does anybody knows which is the newest
> editon of this book.
>
> Thanks for your help
>
> Frank

_Macintosh_C_Programming_Primer_, Vol. 1, is now in its second edition.
$26.95 (US), published by Addison Wesley (1992), written by Dave Mark
and Cartwright Reed.  ISBN#0-201-60838-3.

A little more technical, but also new, is the second edition of
_Macintosh_Programming_Secrets_, by Scott Knaster and Keith Rollin,
also published by Addison Wesley (1992), at $29.95 (US).
ISBN# 0-201-58134-5.


[I have no relation to either of these books, except as a satisfied
customer.  :-)]
- --
Brian D. Davison                    Department of Computer Science
                                    Rutgers, The State University of New Jersey
[e-mail]            Hill Center, 3rd floor, Busch Campus
!rutgers!paul.rutgers.edu!davison   Piscataway, NJ  08855-1179

+++++++++++++++++++++++++++

From: [e-mail] (Stephen Marshall)
Date: Tue, 16 Jun 1992 22:37:21 GMT
Organization: Victoria University of Wellington, New Zealand

Speaking of the C primer, does anyone know if the Pascal primer vol2 has
been written? Or is Dave too busy writting the 2nd edition of the C primer
to complete the pascal?

Stephen

---------------------------

From: [e-mail] (PEGG, DAVID J)
Subject: Think C menu question
Organization: University of Tennessee Computing Center
Date: Wed, 10 Jun 1992 15:58:00 GMT

Hi,

I'm a bit of a novice so I was hoping someone could help me with
a problem.  I'm using Think C 5.0.2 and am having trouble getting
menus to show up on bar.  They work fine, but only one is visible.
I decided to copy a program out of a book ("Using the Macintosh
Toolbox with C" by Huxam et.al.) but still no luck.  I cut it down
to what I thought were the bare essentials to put two menus in the
menu bar.   Still only one appeared. Could someone tell me what I'm
doing wrong?

/*********************************/
MenuHandle            MyMenu,OurMenu;

SetUpMenus()
{
    OurMenu = NewMenu(102,"\pOurMenu");
    AppendMenu(OurMenu,"\pHide;Show/S");
    InsertMenu(OurMenu,0);

    MyMenu = NewMenu(103,"\pMyMenu");
    AppendMenu(MyMenu,"\pFirst;Second/M");
    InsertMenu(MyMenu,0);

    DrawMenuBar();
}

main()
{
    InitGraf(&thePort);
    InitFonts();
    InitWindows();
    InitCursor();
    FlushEvents(everyEvent,0);
    InitMenus();
    SetUpMenus();
    while(!Button())
    {
    }
}
/**************************/

Thanks for any help, Joe Dellwo.

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 10 Jun 92 21:29:16 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail] (PEGG,
DAVID J) writes:
>
> Hi,
>
> I'm a bit of a novice so I was hoping someone could help me with
> a problem.  I'm using Think C 5.0.2 and am having trouble getting
> menus to show up on bar.  They work fine, but only one is visible.
> I decided to copy a program out of a book ("Using the Macintosh
> Toolbox with C" by Huxam et.al.) but still no luck.  I cut it down
> to what I thought were the bare essentials to put two menus in the
> menu bar.   Still only one appeared. Could someone tell me what I'm
> doing wrong?
>
> /*********************************/
> MenuHandle            MyMenu,OurMenu;
>
> SetUpMenus()
> {
>     OurMenu = NewMenu(102,"\pOurMenu");
>     AppendMenu(OurMenu,"\pHide;Show/S");
>     InsertMenu(OurMenu,0);
>
>     MyMenu = NewMenu(103,"\pMyMenu");
>     AppendMenu(MyMenu,"\pFirst;Second/M");
>     InsertMenu(MyMenu,0);
>
>     DrawMenuBar();
> }
>
> main()
> {
>     InitGraf(&thePort);
>     InitFonts();
>     InitWindows();
>     InitCursor();
>     FlushEvents(everyEvent,0);
>     InitMenus();
>     SetUpMenus();
>     while(!Button())
>     {
>     }
> }
>

You're going to hate this, but "It works for me." I took your code, stuck into a
source file, declared OurMenu and MyMenu, and compiled it under THINK C 5.0.2.
Both menus showed up. I ran the program stand-alone and also under THINK C.

If I were in your position, I'd start taking a look at the stuff hanging off of
the low-memory global MenuList. It's documented in the Menu Manager Chapter of
IM V (actually, I think that the information in Inside Mac I is sufficient for
you, and it's a lot clearer than IM V).

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.


+++++++++++++++++++++++++++

From: [e-mail] (Mark Wittenberg)
Organization: Novell, Inc.
Date: 11 Jun 92 00:44:03 GMT

In <[e-mail]> [e-mail] (Keith Rollin) writes:

>In article <[e-mail]>, [e-mail] (PEGG,
>DAVID J) writes:
>>
>> Hi,
>>
>> I'm a bit of a novice so I was hoping someone could help me with
>> a problem.  I'm using Think C 5.0.2 and am having trouble getting
>> menus to show up on bar.  They work fine, but only one is visible.
>> I decided to copy a program out of a book ("Using the Macintosh
>> Toolbox with C" by Huxam et.al.) but still no luck.  I cut it down
>> to what I thought were the bare essentials to put two menus in the
>> menu bar.   Still only one appeared. Could someone tell me what I'm
>> doing wrong?
>>
>> /*********************************/
>> MenuHandle            MyMenu,OurMenu;
>>
>> SetUpMenus()
>> {
>>     OurMenu = NewMenu(102,"\pOurMenu");
>>     AppendMenu(OurMenu,"\pHide;Show/S");
>>     InsertMenu(OurMenu,0);
>>
>>     MyMenu = NewMenu(103,"\pMyMenu");
>>     AppendMenu(MyMenu,"\pFirst;Second/M");
>>     InsertMenu(MyMenu,0);
>>
>>     DrawMenuBar();
>> }
>>
>> main()
>> {
>>     InitGraf(&thePort);
>>     InitFonts();
>>     InitWindows();
>>     InitCursor();
>>     FlushEvents(everyEvent,0);
>>     InitMenus();
>>     SetUpMenus();
>>     while(!Button())
>>     {
>>     }
>> }
>>

>You're going to hate this, but "It works for me." I took your code, stuck into a
>source file, declared OurMenu and MyMenu, and compiled it under THINK C 5.0.2.
>Both menus showed up. I ran the program stand-alone and also under THINK C.

>If I were in your position, I'd start taking a look at the stuff hanging off of
>the low-memory global MenuList. It's documented in the Menu Manager Chapter of
>IM V (actually, I think that the information in Inside Mac I is sufficient for
>you, and it's a lot clearer than IM V).

>--
>Keith Rollin
>Phantom Programmer
>Taligent, Inc.

I'd check to make sure that the menu id field of the menu resources
is in fact 102 and 103, respectively (no, not the resource id, but MenuID,
the first field).  ResEdit doesn't automatically set the first field of
a menu to be the same as its resource id, but if it's different the menu
doesn't show up.  Anyone want to take bets that the MenuID fields
are 128 and 129?  This should be in the FAQ if it's not.

/markw
- --
- ---
Mark Wittenberg            Voice:        [phone]
Novell, Inc.            Internet:    [e-mail]
1340 Treat Blvd. Suite 500    UUCP:        uunet!kinetics!markw

+++++++++++++++++++++++++++

From: [e-mail] (Brain in Neutral)
Date: 11 Jun 92 16:14:38 GMT

>From article <[e-mail]>, by [e-mail] (Mark Wittenberg):
> I'd check to make sure that the menu id field of the menu resources
> is in fact 102 and 103, respectively (no, not the resource id, but MenuID,
> the first field).  ResEdit doesn't automatically set the first field of
> a menu to be the same as its resource id, but if it's different the menu
> doesn't show up.  Anyone want to take bets that the MenuID fields
> are 128 and 129?  This should be in the FAQ if it's not.

Your observations are correct when one is using menu *resources* (I got
bit by this myself last weekend, grrr.)  However, the code in question
uses NewMenu, not GetMenu, so this can't be the answer: no resources are
involved.

    > SetUpMenus()
    > {
    >       OurMenu = NewMenu(102,"\pOurMenu");
    >       AppendMenu(OurMenu,"\pHide;Show/S");
    >       InsertMenu(OurMenu,0);
    >
    >       MyMenu = NewMenu(103,"\pMyMenu");
    >       AppendMenu(MyMenu,"\pFirst;Second/M");
    >       InsertMenu(MyMenu,0);
    >
    >       DrawMenuBar();

Paul DuBois
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 11 Jun 92 18:42:54 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail] (Brain in
Neutral) writes:
>
> From article <[e-mail]>, by [e-mail] (Mark
Wittenberg):
> > I'd check to make sure that the menu id field of the menu resources
> > is in fact 102 and 103, respectively (no, not the resource id, but MenuID,
> > the first field).  ResEdit doesn't automatically set the first field of
> > a menu to be the same as its resource id, but if it's different the menu
> > doesn't show up.  Anyone want to take bets that the MenuID fields
> > are 128 and 129?  This should be in the FAQ if it's not.
>
> Your observations are correct when one is using menu *resources* (I got
> bit by this myself last weekend, grrr.)  However, the code in question
> uses NewMenu, not GetMenu, so this can't be the answer: no resources are
> involved.

Please keep in mind that normally it is just fine for menu IDs to be different
from resource IDs. The problem comes up when you use something that erroneously
(or as a matter of convenience) assumes they are the same. This includes MacApp,
TCL, and the System 7 Popupmenu CDEF. In plain old applications, you can make
the resource ID different from the menu ID.

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.

+++++++++++++++++++++++++++

From: [e-mail] (Mark Wittenberg)
Organization: Novell, Inc.
Date: 11 Jun 92 19:59:32 GMT

In <[e-mail]> [e-mail] (Keith Rollin) writes:

>In article <[e-mail]>, [e-mail] (Brain in
>Neutral) writes:
>>
>> From article <[e-mail]>, by [e-mail] (Mark
>Wittenberg):
>> > I'd check to make sure that the menu id field of the menu resources
>> > is in fact 102 and 103, respectively (no, not the resource id, but MenuID,
>> > the first field).  ResEdit doesn't automatically set the first field of
>> > a menu to be the same as its resource id, but if it's different the menu
>> > doesn't show up.  Anyone want to take bets that the MenuID fields
>> > are 128 and 129?  This should be in the FAQ if it's not.
>>
>> Your observations are correct when one is using menu *resources* (I got
>> bit by this myself last weekend, grrr.)  However, the code in question
>> uses NewMenu, not GetMenu, so this can't be the answer: no resources are
>> involved.

>Please keep in mind that normally it is just fine for menu IDs to be different
>from resource IDs. The problem comes up when you use something that erroneously
>(or as a matter of convenience) assumes they are the same. This includes MacApp,
>TCL, and the System 7 Popupmenu CDEF. In plain old applications, you can make
>the resource ID different from the menu ID.

>--
>Keith Rollin
>Phantom Programmer
>Taligent, Inc.

1.  Yes, thanks, Paul, but I guess "Brain in Neutral" describes me, not
you; I don't seem to have read the source very carefully.

2.  Yes, thanks, Keith, but it's been such a long time since I've programmed
in plain C that I just forgot about it.

So I guess next time I'll read carefully and then think before posting.
Now I remember why I normally reply by mail.

/markw
- --
- ---
Mark Wittenberg            Voice:        [phone]
Novell, Inc.            Internet:    [e-mail]
1340 Treat Blvd. Suite 500    UUCP:        uunet!kinetics!markw
Walnut Creek, CA 94596        AppleLink:    NOVELL.WCENG
                FAX:        [phone]

+++++++++++++++++++++++++++

From: [e-mail] (Robert J. Hall)
Date: 11 Jun 92 17:30:57 GMT
Organization: Boeing Computer Services, Seattle


 > I'm using Think C 5.0.2 and am having trouble getting menus to show up on
 > bar.  They work fine, but only one is visible.

I've run into this problem once or twice. It could be a bug in ResEdit. I
created or copied a new resource file from one of the Think C Demos, copied
the old Menu's into the new resource file, then fired up the program. All
the menu's showed up fine. Pretty wierd, huh? If that fails, you can always
try to DeRez the resource file, then Sarez the result into a new file.

Of course, it could be that your menu ID's are wrong.
- --
  Robert J. Hall
  Systems Analyst, Boeing Computer Services
  "This load of tripe is mine and mine alone."

+++++++++++++++++++++++++++

From: [e-mail] (PEGG, DAVID J)
Organization: University of Tennessee Computing Center
Date: Fri, 12 Jun 1992 18:07:00 GMT

In article <[e-mail]>, [e-mail] (Robert J. Hall) writes...
>
> > I'm using Think C 5.0.2 and am having trouble getting menus to show up on
> > bar.  They work fine, but only one is visible.
>
>I've run into this problem once or twice. It could be a bug in ResEdit. I
>created or copied a new resource file from one of the Think C Demos, copied
>the old Menu's into the new resource file, then fired up the program. All
>the menu's showed up fine. Pretty wierd, huh? If that fails, you can always
>try to DeRez the resource file, then Sarez the result into a new file.
>
>Of course, it could be that your menu ID's are wrong.
>--
>  Robert J. Hall
>  Systems Analyst, Boeing Computer Services
>  "This load of tripe is mine and mine alone."

Thanks, but I found the problem.  I have an extension called NoBalloonMenu
which removes balloon help from the finder menu.  Apparantly it doesn't
know when to stop.  Took it out and everything works fine.

Thanks anyway,
Joe Dellwo
Univ. of Tennesse

+++++++++++++++++++++++++++

From: [e-mail] (John Andrews)
Organization: UIUC Center for Supercomputing Research and Development
Date: Fri, 12 Jun 92 18:39:44 GMT

[e-mail] (Robert J. Hall) writes:

> > I'm using Think C 5.0.2 and am having trouble getting menus to show up on
> > bar.  They work fine, but only one is visible.

>Of course, it could be that your menu ID's are wrong.

Yea, this is a likely cause.  I made this mistake and got the symptom of
only one menu showing up.  Original poster, make sure you set both the
Menu ID and the Menu Resource ID, generally to the same number.  The MDEF ID
is usually set to 0.

- --
John Andrews ([e-mail]) "He who dies with the shortest .sig, wins"
Graduate Research Assistant, Center for Supercomputing R&D, Urbana, IL

+++++++++++++++++++++++++++

From: [e-mail] (Robert J. Hall)
Date: 15 Jun 92 17:29:33 GMT
Organization: Boeing Computer Services, Seattle


 > > > I'm using Think C 5.0.2 and am having trouble getting menus to show up
 > > > on the bar.  They work fine, but only one is visible.

 > > Of course, it could be that your menu ID's are wrong.

 > Yea, this is a likely cause.  I made this mistake and got the symptom of
 > only one menu showing up.  Original poster, make sure you set both the
 > Menu ID and the Menu Resource ID, generally to the same number.  The MDEF ID
 > is usually set to 0.

Yep, that fixed the problem. I guess the fact that the Menu ID was hidden under
an obscure menu pick, instead of the menu dialog in ResEdit, had me fooled into
thinking the Res ID & Menu ID would be the same. *sigh* Live and learn...]

Next problem...I am creating multiple documents in Think C. They each use the
same PopupMenu's. However, each document can have a different pick in the
corresponding popup menu. Now when I select an item in the first document's
popup menu, it also shows up checked in the second document's popup menu.
I've tried various things such as Automatic Checking on or off; trying to
clear and reset the checked items; etc., without success. Short of accessing
the protected menuID variable in the PopupMenu instance, and turning off all
the check marks after a switch between the documents, is there a clean way
to resolve this problem?

The document is being used as a gopher and the Popups are activated by means
of a PopupPane instance under each document.

Thanks in advance for your help!

- --

  Robert J. Hall
  Systems Analyst, Boeing Computer Services

+++++++++++++++++++++++++++

From: 9999cs02@uhdvx3 (Tina Marie!)
Organization: University of Houston-Downtown
Date: Tue, 16 Jun 1992 01:46:00 GMT

(Robert J. Hall) writes...
>
> > > > I'm using Think C 5.0.2 and am having trouble getting menus to show up
> > > > on the bar.  They work fine, but only one is visible.
>
> > > Of course, it could be that your menu ID's are wrong.
>
> > Yea, this is a likely cause.  I made this mistake and got the symptom of
> > only one menu showing up.  Original poster, make sure you set both the
> > Menu ID and the Menu Resource ID, generally to the same number.  The MDEF ID
> > is usually set to 0.
>
>Yep, that fixed the problem. I guess the fact that the Menu ID was hidden under
>an obscure menu pick, instead of the menu dialog in ResEdit, had me fooled into
>thinking the Res ID & Menu ID would be the same. *sigh* Live and learn...]
>

    Okay...I used to do this constatly, until I found out that if you
    change the resource ID for a menu in ResEdit when the menu was open,
    it will ask you if you want to change the Menu ID as well.  Now, I
    never change a resource ID without the menu open.  Saves a lot of
    hours of debugging.

>Next problem...I am creating multiple documents in Think C. They each use the
>same PopupMenu's. However, each document can have a different pick in the
>corresponding popup menu. Now when I select an item in the first document's
>popup menu, it also shows up checked in the second document's popup menu.
>I've tried various things such as Automatic Checking on or off; trying to
>clear and reset the checked items; etc., without success. Short of accessing
>the protected menuID variable in the PopupMenu instance, and turning off all
>the check marks after a switch between the documents, is there a clean way
>to resolve this problem?
>
>The document is being used as a gopher and the Popups are activated by means
>of a PopupPane instance under each document.
>
>Thanks in advance for your help!
>

    Okay.  I had a similar problem not long ago, and I came up with two
    solutions.

    A) Read in the menus from string list resources, and build them on
    the fly, making sure to give each one a unique menu ID.

    B) (what I did) Subclass CPopupMenu, overridding PopupSelect and
    GetCheckedItem. Add your own instance variable to keep track of the
    currently checked item.  At the top of PopupSelect, uncheck the menu
    item that is checked, and check yours.  After an item is selected,
    set yours again.  Also, you'll need to override GetCheckedItem, or
    the wrong value may be displayed in your PopupPane after a refresh.

    B) also works well if you want to do anything else neat, like add
    hierarchical menus that need to be underlined instead of checked.

    If you still have problems, send me e-mail, and I'll be more
    detailed.

    Tina Femea

    Aspiring to be a Mac Wizard
    [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Robert J. Hall)
Date: 16 Jun 92 21:49:33 GMT
Organization: Boeing Computer Services, Seattle


 > B) (what I did) Subclass CPopupMenu, overridding PopupSelect and
 > GetCheckedItem. Add your own instance variable to keep track of the
 > currently checked item.  At the top of PopupSelect, uncheck the menu
 > item that is checked, and check yours.  After an item is selected,
 > set yours again.  Also, you'll need to override GetCheckedItem, or
 > the wrong value may be displayed in your PopupPane after a refresh.

Yup, that's more or less what I came up with. I didn't think of the refresh
fix in GetCheckedItem, however. Thanks for the tip! Now on to CEditText...
- --

  Bob Hall - Systems Analyst, Boeing Computer Services

---------------------------

End of C.S.M.P. Digest
**********************